The present invention relates generally to systems implementing wireless radio signal transmissions and mobile content management. More particularly, this invention relates to the deployment and management of location-based technologies in the context of mobile content management systems. An exemplary embodiment of location-based technologies as described herein includes a managed network of Bluetooth Low Energy (“BLE”) beacons, but alternately may include for example near field communication (NFC) applications, or even QR codes and the like.
The emergence of BLE beacons is one of numerous recent technological factors wherein consumers are increasingly enabled to interact directly with their surroundings, discovering new content, retrieving information “served up” because of its contextual relevance, and responding with their feedback and desires.
There are several protocols in the market over which BLE beacons operate, including for example Apple's iBeacon protocol, which consists of a fixed length bit package (UUID/Major Identifier/Minor Identifier) that is in turn interpreted by compatible mobile Apps. However, in order to truly unlock the potential for interaction with any “smart device” upon demand, it would be desirable to reduce or eliminate the need for users to download an app associated with each respective group of devices. In keeping with the objective of rapid expansion of the Web into the physical world, it is therefore desirable to make the process of adding an element just as simple as adding a new web page.
Alternative and open source protocols such as for example UriBeacon and Eddystone-URL have been implemented, and may be referred to herein as Physical Web beacons, wherein the beacons broadcast a Uniform Resource Identifier (“URI”) such as without limitation a Uniform Resource Locator (“URL”) or uniform Resource Name (“URN”), in the context of accessing a network location such as a website address. As used herein, URI may refer interchangeably to a unique identifier associated with a beacon, a URN, or a URL, except in instances where the URL is specified as including the unique identifier associated with the beacon (the URI). The Physical Web has been promoted as a primary link between the physical world and the Internet, where places and things in can communicate via websites. Much like QR codes, Physical Web beacons will be universally accessible, and will not require a custom App, as are required by for example the iBeacon protocol.
The conventional mode of operation with a Physical Web beacon is straightforward. With an administrative App designed to configure beacons, and when physically near to the target beacon, one can connect with a Physical Web beacon and program it with the URI in combination with a network location and methodology of retrieving content from said destination—in practical terms a URL. The target beacon references this URI to broadcast the desired URL. A special browser executable from a client device is configured to read the broadcast from that beacon and connect to the destination URL in the normal way.
However, in order to connect to current Bluetooth beacons such as a UriBeacon or Eddystone beacon and change the URL which it advertises, the user must be physically near the beacon, because the process is accomplished over a Bluetooth low energy link, which has a limited range. This proximity requirement can be particularly problematic where the user wishes to implement and provide periodic updates for numerous beacons across an inconveniently large area, or otherwise make appropriate range settings for a suitable user experience. The associated need for an unfamiliar, and sometimes awkward, programming task (e.g., taking the beacon's batteries out, or pushing a button) inhibits an otherwise familiar and straightforward process. This task is made unmanageable for widely dispersed installations by the requirement to have to handle each beacon in order to adjust its settings. Therefore, it would be desirable to eliminate the requirement of locally and directly interacting with the beacon for configuration by enabling a network-based management platform for the plurality of beacons in a dispersed installation.
Further, another limitation of the Eddystone and UriBeacon protocol is that the maximum size of the advertisement data field is 17 or 18 characters respectively (at present), so for example:                www.xxxxYYYY.comfits fine, whereas:        https://github.com/google/uribeacon/tree/master/specificationwill not fit.        
For this reason, domain name shortening services are recommended and are commonly used with Eddystone beacons and UriBeacons. In the above example, if the second URL were plugged into the “Goo.gl” domain shortening application, the user would obtain http://goo.gl/Du29uS. If the user clicks on this link, he/she will be directed to the original link, but first must go to http://Goo.gl, where the link will be translated before redirection to the correct site. This short-URL to destination-URL relationship can be problematic because additional URL information appended to the shortened URL, such as UTM codes, location information, or other information tags are lost when the shortened URL is translated into the destination URL. It would therefore be desirable to eliminate not only the step of interacting directly with the beacon, but further or at least in the alternative to eliminate the requirement of having to use third-party domain shortening applications for destinations having more than 18 characters, and to provide a methodology where contextual information appended to a shortened URL can be transferred to the associated destination URL.
Another problem in conventional applications is that websites currently have embedded content that is displayed by a browser upon search. These typically include the website's title, its favicon, and its description. Because this information is embedded in the website, it is not easily changed without making direct changes to the website. For websites displayed on a beacon browser (e.g., Physical Web browser) it would be beneficial if the title, favicon, and description of a website could be dynamically changed.
For example, if a restaurant's menu is on a website to be accessed and reviewed by people near to the restaurant, then it would be desirable to the restaurant owner to be able to change the title for that website (as displayed on a person's browser) to say “Meat Loaf Special today” or “2 for 1 PBR's” or “Free appetizer's for the next hour” or whatever message the restaurant wants to broadcast in order to capture the attention of passerby's when they scan for location-based websites, and it is preferred that this can be done without having to change the underlying website.
Still another problem with conventional techniques is that beacons currently broadcast content through simple strings including URLs. As such, they are a powerful platform to make relevant content available to consumers in physical locations. However, if multiple beacons broadcast the same URL, then the source location of the user who accesses the beacons is lost. It would therefore be desirable that when location based content is accessed, and when more than one location is associated with that content, that the point of origin of each access can be accurately identified.